<html>
 <head>
  <meta charset="UTF-8">
 </head>
 <body>
  <h1 data-lake-id="WTFVQ" id="WTFVQ"><span data-lake-id="ud900b165" id="ud900b165">典型回答</span></h1>
  <p data-lake-id="udc76ec06" id="udc76ec06"><br></p>
  <p data-lake-id="u64cb2531" id="u64cb2531"><span data-lake-id="u44317711" id="u44317711">一百个架构师眼中，有100种微服务拆分的方式，那么我简单总结几个我在做类似的事情的时候会参考的一些原则：</span></p>
  <p data-lake-id="uea07239c" id="uea07239c"><span data-lake-id="u5a529bb6" id="u5a529bb6">​</span><br></p>
  <p data-lake-id="u1aa38aed" id="u1aa38aed"><span data-lake-id="u08df42e1" id="u08df42e1">1、职责。我们学面向对象的第一天，就被告知要职责单一，而一个微服务也一样，他应该聚焦干一件事儿，否则他就不够"微"，至少在电商中，我们要把用户和交易拆分开。</span></p>
  <p data-lake-id="u135bb619" id="u135bb619"><span data-lake-id="u78e373de" id="u78e373de">​</span><br></p>
  <p data-lake-id="u3834148d" id="u3834148d"><span data-lake-id="ue351b2cf" id="ue351b2cf">2、业务。我们说技术是为了业务服务的，所以微服务的构建需要围绕着业务来做，不同的业务需要独立出来，比如保险业务中，投保和理赔，就是不同的业务，那么就可以把他们拆分开。</span></p>
  <p data-lake-id="u8462c419" id="u8462c419"><span data-lake-id="u78d36663" id="u78d36663">​</span><br></p>
  <p data-lake-id="uc672fc25" id="uc672fc25"><span data-lake-id="u9bbd41aa" id="u9bbd41aa">3、中台化。当我们在做业务拆分、职责划分后，可能会有一些公共的部分，这部分内容分别在各自微服务实现一份也可以，单独独立出来也是可行的，所以如果考虑中台化的思想，一些公共的部分，是可以独立拆分出来的。</span></p>
  <p data-lake-id="u95b45d6d" id="u95b45d6d"><span data-lake-id="ue49132bb" id="ue49132bb">​</span><br></p>
  <p data-lake-id="ufc72a024" id="ufc72a024"><span data-lake-id="u6d6fd9ec" id="u6d6fd9ec">4、系统保障。在做微服务拆分的时候，可能需要根据不同的系统保障级别做拆分，比如秒杀和日常交易，就可以单独拆开，针对秒杀做单独的可用性保障。还有一种就是在线任务和离线任务，也是可以拆分开的，各自做可用性保障。</span></p>
  <p data-lake-id="u5a6a33c4" id="u5a6a33c4"><span data-lake-id="ued9bc70b" id="ued9bc70b">​</span><br></p>
  <blockquote data-lake-id="u4add43db" id="u4add43db">
   <p data-lake-id="u7ab83497" id="u7ab83497"><span data-lake-id="u8eca35c5" id="u8eca35c5">在线任务：就是你应用中一直都在运行的任务，比如你的订单系统，他的下单、退款正常这些操作都是在线任务。</span></p>
   <p data-lake-id="ua9374fee" id="ua9374fee"><span data-lake-id="u867083d0" id="u867083d0">离线任务：一般是那种异步扫表、或者定时执行的任务，比如订单的到期关闭等。</span></p>
  </blockquote>
  <p data-lake-id="uc9632528" id="uc9632528"><span data-lake-id="u2437e2ff" id="u2437e2ff">​</span><br></p>
  <p data-lake-id="ue980b6f2" id="ue980b6f2"><span data-lake-id="ud9218f5b" id="ud9218f5b">5、技术栈。要考虑技术栈，不同的技术栈，不要硬往一起融，最后只会让这个系统无法维护。</span></p>
  <p data-lake-id="u2d96fb64" id="u2d96fb64"><br></p>
  <p data-lake-id="u5518f089" id="u5518f089"><span data-lake-id="u3772e6be" id="u3772e6be">6、依赖关系。拆分之后，各个微服务之间，不要有循环依赖。依赖应该是单向的，而不是循环的，循环依赖会给服务治理，链路追踪带来很大的挑战，并且存在循环依赖一定是拆分的不够合理</span></p>
  <p data-lake-id="u9905ce1d" id="u9905ce1d"><br></p>
  <p data-lake-id="ua0b53c28" id="ua0b53c28"><span data-lake-id="ud1fd36f5" id="ud1fd36f5">7、康威定律。最后一点，康威定律，应用架构要和组织架构一一对应。组织架构决定了业务架构、应用架构。说白了，就是多个团队一起维护一个微服务，一定会存在沟通、（发布）冲突、谁来干等问题。</span></p>
 </body>
</html>